With the increasing popularity of computing devices, more and more data gets stored in relational databases. Information stored in databases routinely gets accessed via the Internet. Today, users access data stored in databases via personal computers (PCs), handheld computers, smart phones and the like. Accordingly, many companies provide for services whereby a vendor can upload database information thus allowing authorized customers and clients to access resources from those databases.
Both commercial (e.g., Oracle-brand, Sybase-brand, DB2-brand) and non-commercial (e.g., Exodus-brand, Postgres-brand) database management systems (DBMSs) are being used to provide for access to such resources. Unfortunately, mechanisms are not provided that isolate and control sharing between resources in these disparate databases within the same server, under security execution contexts different from that of the caller.
As more and more information gets stored in DBMSs, applications built over these DBMSs begin to function as trusted sub-systems. A trusted sub-system based security model differs from an access-control-against-the-end-user based security model in that in the former, security checks are performed at the point-of-entry. After the security check is successful, the trusted subsystem elevates to a privileged context and accesses data in that context.
Traditionally, DBMS products, which act as a platform for data-centric applications, support an access control based model. Unfortunately, this model falls short of its ability to perform complex operations as illustrated in the SAP-brand, BaaN-brand and PeopleSoft-brand of products. Consequently, those applications frequently implement a trusted sub-system based model completely separate from the database system. In other words, conventionally, these trusted sub-system based models are implemented in a disparate process. This separation causes the transport between the database system and the application process to be very secretive and often results in an abuse of the security capabilities of the DBMS.
Conventional systems do not provide a specification and implementation of a security execution context within a DBMS that autonomously supports capabilities to build trusted sub-system based applications. Accordingly, these traditional systems do not provide an implementation of a security authorization model that independently allows for these isolation and controlled share features to simultaneously ensure that the newly impersonated context is sand-boxed to the correct privilege levels.